Fuelling arrangement and method

ABSTRACT

A method of fuelling an aircraft for a flight to a predetermined destination in which the aircraft is loaded, the actual zero fuel weight of the loaded aircraft is determined, the fuel requirement of the loaded aircraft for that destination is calculated by fuel calculation software on the basis of operational flight plan data, said actual zero fuel weight, and further data relevant to fuel consumption for that instance of the flight to the predetermined destination, said further data being processed interactively by the user by means of a user interface to said fuel calculation software, and subsequently fuel to meet said fuel requirement is uplifted to the aircraft under the control of said user.

The present invention relates to a fuelling arrangement and method,particularly but not exclusively for fuelling an aircraft, such as apassenger or cargo-carrying commercial airliner or a military aircraftfor example.

Airline operators face severe challenges in operating profitably.Airlines also face increasing pressure to reduce carbon emissions andthe associated footprint. A key factor in this is reducing fuelconsumption to the lowest level possible, consistent with safety.

Preparations are in place for emissions trading in Europe (and in otherparts of the world). Virtually all airlines with operations to, from andwithin the European Union (EU) will come under the scope of the EU'sEmissions Trading Scheme (ETS) from 2012. Airlines were required tosubmit a monitoring plan by August 2009 and to monitor data from 2010.On 2 February 2009, EU legislation (Directive EC/2008/101) came intoforce incorporating aviation into the EU ETS as from 2012. It isunderstood that civil aviation is one of the fastest growing sources ofgreenhouse gas emissions, showing long term compound annual growth ratesof emissions of 3 to 4%. A key policy objective of the EU ETS will be toreduce airline emissions to the level at 2005 by 2050.

Many efforts are being made by the industry to achieve fuel savingsthrough a variety of factors from aircraft design to operatingprocedures.

Currently, a passenger-carrying and/or cargo-carrying commercialaircraft is re-fuelled to a standby figure before and during loading andthen topped up before push-back (tow vehicle manoeuvres the aircraft forengine start) prior to take-off with a total quantity of fuel set by anOperational Flight Plan (OFP) which is prepared by specialist groundstaff typically two or three hours before take-off and takes intoaccount the following:

-   i) the aircraft type (eg Boeing B777 (RTM)) and the manufacturer's    fuel consumption data for that type;-   ii) a degradation factor determined empirically for that particular    aircraft, which modifies the fuel consumption data of i) above by a    percentage which is dependent on the age and condition of the    airframe (for example dents will raise the fuel consumption);-   iii) the anticipated aircraft weight(s);-   iv) the anticipated route, speeds and flight levels;-   v) expected taxiing time from the ramp (embarkation/loading point)    to the runway, to allow for taxi fuel;-   vi) anticipated meteorological conditions; and-   vii) ATS (Air Transport Safety) procedures and restrictions (for    example Final Reserve Fuel is carried to enable 30 minutes' flying    at holding speed above the destination airport and Contingency Fuel    is carried to allow for deviations from the expected route and    weather conditions and to allow for a margin of error).

Typically, the OFP is passed to the captain in the form of a printedsheet shortly before boarding, or, as in some systems (e.g. the Cirrus™system), the OFP is transmitted electronically to the cockpit. Ittypically includes some guidance on modifying the fairly sophisticatedfuel calculation used to generate the minimum fuel requirement listed inthe OFP. For example, it will include an Estimated Zero Fuel Weight(EZFW) value for the aircraft which is the estimated total weight(including passengers, cargo and crew) but excluding the weight of thefuel. The Actual Zero Fuel Weight (AZFW) is determined after theaircraft has been loaded and is typically less than the EZFW becausesome passengers fail to embark or some cargo is not loaded. Whilst AZFWis more accurate that EZFW because it is based on accurate information(e.g. actual number of passengers boarding aircraft and weight ofcargo), it should be noted that the values for AZFW are not accuratelydetermined since they are typically based on estimates of passengerweights and hand luggage allowances. Accordingly the OFP gives thecaptain estimated values (typically based on accurate information) as anAZFW with which to adjust (typically, to reduce) the minimum fuelrequirement in order to take this change in circumstances into account.

However this is a matter of discretion and, typically, not every changein circumstances which would lead to a change in minimum fuelrequirement is flagged up by the OFP. For example, a change in runwaywill affect the taxiing time and hence the minimum fuel requirement.

The aircraft captain also has discretion to add extra fuel (“ExtraFuel”) to that mandated by the OFP and often does so on the basis ofe.g. changes in the weather or other factors of a more subjectivenature, including lack of confidence in or ignorance of the safeguardsbuilt in to the fuel calculation. There is currently no consistencybetween the behaviour of captains in taking this action and there arecurrently no consistent guidelines provided to them.

In many cases the Extra Fuel is unnecessary. Since the fuel payload ofan airliner is typically a significant proportion of the total weight ofthe aircraft, carrying this fuel involves significant extra fuelconsumption of the order of 3-4%/hr of flight. So, for example, if onetonne of Extra Fuel were carried unnecessarily on a 12 hour flight,12×4%=48% of the Extra Fuel would be burnt carrying its own weight,leaving only 520 kg of the Extra Fuel in the tank for future use onarrival at the destination. In other words, 480 kg of fuel would becompletely wasted. This calculation disregards the additional fueldemands on take-off and landing imposed by the Extra Fuel. It also doesnot allow for the fact that this waste also leads to the production ofadditional carbon dioxide that could be avoided.

On the other hand, until and unless it may become the case that all fuelcalculations are the sole responsibility of ground operations, it wouldnot be prudent or acceptable to a captain to prevent him from uploadingExtra Fuel; an element of discretion must be left in order to take intoaccount discrepancies between the actual conditions and those on whichthe operational flight plan was predicated.

An object of the present invention is to overcome or at least alleviatesome or all of the above problems.

Accordingly the invention provides a method of fuelling an aircraft fora flight to a predetermined destination wherein the aircraft is loaded,the actual zero fuel weight of the loaded aircraft is determined, thefuel requirement of the loaded aircraft for that destination iscalculated by fuel calculation software on the basis of operationalflight plan data, said actual zero fuel weight, and further datarelevant to fuel consumption for that instance of the flight to thepredetermined destination, said further data being processedinteractively by the user by means of a user interface to said fuelcalculation software, and subsequently fuel to meet said fuelrequirement is uplifted to the aircraft under the control of said user.

-   Preferably said further data is entered at said user interface by    the user. This enhances the involvement of the user in the fuel    calculation and reduces the temptation to carry unnecessary extra    fuel.

It is highly preferred that the user interface is on the aircraft,preferably on the flight deck, e.g. in the form of a screen and keyboardof the captain's laptop computer.

Typically the operational flight plan (OFP) data will include parametersdependent upon some or all of items i) to iv) and vii) noted above andthe user (normally, the captain of the aircraft or perhaps the co-pilotor another responsible member of the flight crew) will be prompted toenter further data such as one or more of: the time expected to be spenttaxiing to the runway (and expected taxiing time at destinationairport), the holding time at the destination airport, the amount ofcontingency fuel carried and weather information (e.g. at departure,en-route and at destination), for example. Such data, even if includedin the OFP, is liable to change between the time the OFP is generatedand the time of final fuelling.

Optionally, the user will still be given the opportunity to add extrafuel but the interaction between the user and the further data using theuser interface is expected to inspire further confidence in the fuelcalculation and in practice to reduce the incentive for extra fuel whichin nearly all cases should be unnecessary. Optionally, the user mayoverride the fuel calculation software and enter its own figures, butshould these figures be less than the calculated fuel requirementproduced by the software, it is preferable that a warning system alertsthe user (by visual or oral means—e.g. a warning notice or an alarmsignal) and optionally other users or a third party, especially if thefigures entered may result in a material breach of internal (airlinespecific policy) or industry safety rules.

A fuel calculation software used in accordance with the presentinvention is preferably configured to provide fuel requirement valuesfor the loaded aircraft for the flight to the predetermined destination,which values include a safe contingency fuel amount. The safecontingency fuel amount is preferably programmed into the software andis typically selected to be at least the amount of contingency fuelrequired by industry regulations and optionally an amount determined byairline policy, the method of calculating contingency fuel beingvariable to account for adjustments in regulations and policies.

Even disregarding the above confidence factor, the improved accuracyobtainable by basing the calculation on current (dynamic) conditions isexpected to result in fuel savings of up to 5%, e.g. from 0.5% to 4% andgenerally at least within the range 1% to 2.5%. Typically a printed OFPwill give a fuel requirement to a precision of three significant figuresso a saving of 1% is certainly significant. This also represents a largeimprovement in profit in a low-margin and highly competitive industry,as well as a significant reduction in carbon dioxide emissions whichwill have positive environmental and financial implications.

The user, as used herein in connection with fuel calculation software ofthe invention, an interface therefor, an aircraft (to which the fuelcalculation software is applied), a computer programme according to theinvention and computer so programmed, may be any user for whom the fuelcalculation software could be effective (e.g. a person or group ofpeople charged with responsibility for fuelling an aircraft with theappropriate amount of fuel for a flight, or a person or other entityresponsible for an automated system for the same, or in the event thatthe control of fuelling is by an automated or computer system such as athird party planning solution, the user may be a third party flightplanning solution configured to communicate via an applicationprogramming interface or API). The user may be, for example, any one ormore of the captain, first officer, second officer, flight crew,technical crew, cockpit crew, pilot, co-pilot, flight dispatcher, flightoperations staff, navigation services staff, company administrator, ITdepartment staff, any management position holder or any other personnelof an organization responsible for aircraft fuelling and relatedefficiency activities (or an electronic user such as a suitablyprogrammed flight planning solution system). As used herein, the user orany user type specified above may be substituted by generic user orother specific user where the context allows.

Preferably the data used includes statistical data based on previousinstances of flights to said destination and selectably the statisticalrecords of the operations of the individual aircraft or the type ofaircraft and/or the individual pilot and the method includes means forreporting actual fuel consumption data after said flight. This ispreferably performed by the user at the user interface and has thefollowing advantages:

-   i) it enables the user to check actual fuel consumption against    calculated fuel consumption and gives further confidence in the    method; and-   ii) it enables the accuracy of the method to be improved by    fine-tuning the operational flight plan data and/or the processing    of the information entered by the user.

The invention also includes a computer program product comprising acomputer-readable medium incorporating program code executable by aprocessor to implement the above processes and methods.

A typical process for calculating the fuel requirement for a flight byan aircraft to a pre-determined destination in accordance with theinvention may include provision of a fuel calculation software orarrangement or such programmed computer and the provision of OperationalFlight Plan (OFP) data. The Operational Flight Plan (OFP) is generallyused herein in a generic sense and may include (the context assisting)an initial OFP, a revised OFP or a final/Master OFP (the latter beingthe Operational Flight Plan that the flight actually follows). As far asthe method, arrangement/system and software according to the inventionare concerned, OFP data (typically initial OFP data generated by groundstaff or an OFP generating system in use by the airline) is an input tothe method, arrangement/system and software of the invention and itssource is not critical to the present invention, but the source shouldpreferably address necessary regulatory compliance matters. OFP data maybe communicated electronically to a system or arrangement comprising acomputer programmed to produce fuelling information according to theinvention, or may be manually entered (e.g. by the user via a physicalinterface) or may be transferred by way of an Application ProgrammingInterface (API) between an application producing fuelling informationaccording to the invention and a system for producing or generatingOperational Flight Plans and associated data. Optionally, thearrangement for calculating the fueling requirement for an aircraft(and/or software or programmed computer therefore) according to thepresent invention may be adapted to form a part of or to seamlesslyintegrate or communicate with an operational flight planning system ofwhich several exist.

In another aspect the invention provides an arrangement for calculatingthe fuel requirement of an aircraft flight to a predetermineddestination, the arrangement comprising means for determining the actualzero fuel weight of the aircraft after it has been loaded, a programmedcomputer arranged to determine a fuel requirement for said flight on thebasis of operational flight plan data, said actual zero fuel weight, andfurther data relevant to fuel consumption for that instance of theflight to the predetermined destination, said computer being programmedto process said further data interactively with a user at a userinterface thereof.

Preferably said computer is arranged to receive said further data as aninput at said user interface from the user. This enhances theinvolvement of the user in the fuel calculation and reduces thetemptation to carry unnecessary extra fuel.

It is highly preferred that the user interface is on the aircraft,preferably on the flight deck, e.g. in the form of a screen and keyboardof the captain's laptop computer.

Preferably said arrangement comprises a computer network including afirst terminal which in use prompts the user to enter said information,said terminal being located on the aircraft, and a second terminal whichin use transmits said operational flight plan data to said firstterminal over said network.

Preferably said first terminal is arranged to transmit actual fuelconsumption data for the completed aircraft flight to the network. Thisenables the interactive fuel calculation software to learn from theactual fuel consumption data and improve its accuracy on subsequentflights.

The network is preferably arranged to connect a plurality of softwaremodules which exchange information, the modules including an interactivefuel calculation module (referred to below as the DYNAMIC module) whichcalculates said fuel requirement and optionally a MANAGEMENT modulewhich typically comprises the algorithms upon which the calculations arebased and which may be accessed by technical staff and/or a COMPLETEmodule which is used to record completed flight data and fuelconsumption for comparison with predicted information. The MANAGEMENTmodule, if the system is so configured may communicate with an externaloperational flight plan module or system which generates operationalflight plan data (or may be integrated with or form a part of an OFPsystem). The naming of modules herein is for convenience and should beconsidered in no way limiting.

Preferably the modules further include a module (referred to below asthe COMPLETE module) which in use acquires actual fuel consumption dataat the end of the flight (e.g. by prompting the user to enter such data,or by receiving fuel consumption data from the aircraft instrumentation)and transmits the actual fuel consumption data to the system management(“MANAGEMENT”) module or to an operational flight plan module or system.

Another module, HISTORICAL, may be used to maintain a database ofinformation concerning all aspects of external factors and their impacton the operational flight plans produced (e.g. by or in association withthe MANAGEMENT module) and the calculations (e.g. of the DYNAMICmodule). Preferably, the data is continually updated. Optionally, thedata provided to the COMPLETE module (i.e. post-flight data) may also besubmitted to the HISTORICAL database, in an anonymous fashion. The datain HISTORICAL may optionally be subject to a pattern recognitionalgorithm to identify inaccuracies in the HISTORICAL data used. Forexample, using such bulk data, it may be possible to determine that anefficiency deterioration factor needs to be increased for aircraft of aparticular type as it ages, etc.

Such modular software has the advantage that different modules may beupdated or modified independently.

The modules may be run on the same or different computers of the networkbut a thin client architecture is preferred in which the modules are allrun on a server (typically on the ground) and the user's computer(typically on the aircraft) acts essentially as a terminal. This has anadvantage that all users can benefit from upgrades (and the latestinformation) simultaneously.

A preferred embodiment of the invention is described below by way ofexample only with reference to FIGS. 1 to 7 of the accompanyingdrawings, wherein:

FIG. 1 is a diagrammatic illustration of an aircraft flight including arefuelling operation calculated by a method and arrangement inaccordance with the invention;

FIG. 2 is a diagram of the software modules utilised in the arrangementof FIG. 1;

FIG. 3 is a diagrammatic initial screenshot generated by the softwaremodules when run on the network of FIG. 1;

FIG. 4 is a diagrammatic screenshot for an algorithm which generatesgeneric OFP fuel consumption data;

FIG. 5 is a diagrammatic screenshot generated, e.g. by the MANAGEMENTmodule, for an alternative algorithm which generates route-specific OFPfuel consumption data;

FIG. 6 is a diagrammatic screenshot generated by the DYNAMIC module onthe aircraft at the data entry stage, and

FIG. 7 is a diagrammatic screenshot generated by the COMPLETE module onthe aircraft at the data entry stage (at the end of the flight).

Referring to FIG. 1, which gives an overview of the arrangement andmethod, an airliner A (in this case a Boeing B777(RTM)) is shown at theramp of terminal T1 about to taxi to a runway R1 prior to take-off. Thecaptain has the required software installed onto his on-boardtough-notebook (class 1 & 2 device) or electronic flight bag (EFBs)class 3 device and runs a DYNAMIC software module after the aircraft hasbeen loaded and the actual zero fuel weight (AZFW) of the aircraft hasbeen determined. AZFW is determined by summing the known pre-loadedaircraft weight with typically an actual determined weight of baggageand an actual determined weight of passengers and crew (and theircarry-on baggage) or an estimated weight of passengers and crew (andtheir carry-on baggage) according to a specific standard (which may bean internal, national or international authority standard). For example,a standard that may be used for calculating passenger weight is: i) 15kg for a child under 2 years; ii) 40 kg for a child aged 2-13 years; andiii) 86 kg for an adult aged over 13 years (additional 3-5 kg may beadded in winter months to account for average increase in weight ofwinter clothing). Alternatively, actual carriage weight could, inprinciple, be determined by utilizing strain gauges or the like fittedto the undercarriage or suspension system of the aircraft. A weightdetermining means or strain-gauge means or the like adapted to fit orreleasably attach to an aircraft, e.g. undercarriage or suspensionsystem, to enable aircraft carriage load weight to be determined priorto takeoff is a further aspect. Optionally, said means is configuredwith a communication means for communicating the carriage load weight toa microprocessor and/or for use of the carriage load weight as inputdata into the method of fuelling and arrangement for calculatinginventions herein defined.

As an option, in order to facilitate an actual determined weight ofpassengers and crew (and their carry-on baggage), which may be utilizedas input data (or further data) in the method of fuelling andarrangement for calculating inventions herein defined, e.g. as inputdata for the DYNAMIC or LIVE modules described, there is provided, forgenerally applicability, as a further aspect of the invention a methodof determining the actual individual and/or combined weight ofpassengers (typically boarding pass-carrying passengers) and/or crewintending to board an aircraft, the method comprising providing aweighing device for weighing individual or groups of passengers and/orcrew who engage said weighing device (e.g. by standing on it for aminimum set time) and requiring all passengers and/or crew intending toboard or boarding the aircraft to engage said weighing device, recordingthe data for individual and/or groups of passengers and/or crew and,preferably, calculating therefrom a total passenger and/or crew weightfor the flight. Preferably, the weight data stored is storedelectronically and communicated by electronic means as input data to aflight-specific calculation in a microprocessor loaded with a fuelcalculation software. Preferably, individual passenger and/or crewweight data may be attributed to the individual passenger and/or crewmember by further requiring that the passenger and/or crew providesidentification (e.g. by way of a boarding pass or id card) to enableweight data to be attributed to the individual (e.g. by a boarding passreader or identification pass reader configured to be in electroniccommunication with a microprocessor receiving individual weight data).Preferably, the passengers and/or crew are required to be weighed withthe hand luggage they intend to carry on board. [Optionally, in afurther aspect, a passenger may be required to provide identificationassociated with payment details, e.g. a credit card or loyalty cart,whereby charges may be applied or rebate issued according to apre-determined scale according to whether the passenger is above orbelow pre-determined maxima and minima boarding weights included in thepurchase price. Such additional charge and/or rebate system may act asan incentive to reduce weight in carriage].

In a further, associated, aspect, there is provide a system fordetermining the weight of passengers and/or crew boarding an aircraft,the system comprising a weighing station comprising a weighing devicefor measuring the weight of a passenger or crew member engaging theweight device and generating individual weight data and anidentification means for identifying the passenger or crew member beingweighed, said weighing device and identification means preferably beingconfigured such that individual weight data is attributed to specificpassenger or crew member. The system further comprises a microprocessoror communication means for storing and/or communicating the individualor cumulative weight data and identification information, optionallyco-attributed. The weight and identification data generated may then beused as input data or further data (e.g. to the DYNAMIC or LIVE modulesdescribed) for the calculation of flight fuel requirement for aspecified aircraft flight. In one embodiment, the system is configuredto weigh the passengers and/or crew without their carry-aboardhand-luggage by, for example, conducting the weighing step during thescanning of hand-luggage routinely carried out at airports as a securitymeasure, the hand-luggage being weight cumulatively on a separateweighing device configured to fit in-line with a scanning system.Preferably, however, in order to provide the most accurate data, thesystem is configured to enable weighing of passengers and/or crew withtheir hand luggage and preferably as close as possible to the boardingof the aircraft, e.g. at the departure gate or at (e.g. just before orjust after) the door to the aircraft. [Optionally, the system is furtherprovided with a payment card reader, such as a credit card reader, or isconfigured to associate the boarding pass or id card to a paymentmethod, and which system is programmed to draw a further charge or issuea rebate from the payment means according to whether the weightattributed to that passenger and its hand luggage is greater than orless than pre-determined limits included in a ticket price].

The AZFW as discussed above is typically an estimated value based uponaccurate information (e.g. actual number of passengers with estimatedweight, estimated weight of hand luggage and actual weight of cargo),which we may term standard-AZFW. Preferably, the AZFW is an accuratelydetermined value, which herein means that actual passenger weight andactual cargo weight is utilized in the AZFW value calculation, which maybe referred to as accurately determined-AZFW. Where the AZFW is anaccurately determined value (e.g. as discussed above), the term AZFWused herein may optionally be substituted with accuratelydetermined-AZFW (or AD-AZFW) as a preferred feature.

As explained in more detail below, the Captain enters the AZFW value andother last-minute information such as the actual runway (R1) whichaffects the taxiing time and hence taxiing fuel consumption, theexpected weather and the expected holding time at the destinationterminal (T2). The DYNAMIC software module calculates the parameters ADJRAMP FUEL (total fuel, which illustrates the weight of fuel required tobe uploaded (at the ramp) to the aircraft for the flight), TRIP & TAXI(the expected fuel consumption during flying and during taxiingrespectively) and displays HISTORICAL FACTS for EXPECTED HOLDING(information on the expected fuel consumption during holding beforelanding at the destination runway R2, explained in detail below) andPREDICTED LDG FUEL (the predicted quantity of fuel remaining onlanding). This is based on the data entered together with datapredictions from software algorithms provided to the DYNAMIC module froma MANAGEMENT software module. Note, it is usual practice to fuel anaircraft to some quantity less than that proposed on the OFP, to allowfor adjustments in fuelling calculations by the captain, for exampleallowing more up-to-date information on cargo weight and passengernumbers. This depends upon an airline policy and aircraft type, but maybe OFP minus 3 tonnes for example. The total calculated fuel requirementfor the flight is the standby fuel figure (that initial fueling amount)plus the additional amount added at the ramp as a result ofcalculations—this is the ADJ RAMP FUEL, being the total desired fuellinglevel determined at the ramp.

The above algorithms incorporate safeguards based on regulatoryrequirements which ensure that the minimum fuel needed to satisfy theserequirements is carried.

The algorithms take into account the fuel required to start the mainengines 2, the fuel used by the aircraft's auxiliary power unit (APU) 1,the fuel used during taxiing to runway R1 and from runway R2, the fuelexpected to be used in flight and the fuel used on landing.

The captain has discretion to increase the quantity of fuel actuallyuplifted to the aircraft, as in the prior art based on printedoperational flight plans, but the interactive software incorporated inthe DYNAMIC module enables him to calculate the implications of this—forexample the amount of the additional fuel that will be expended simplyin carrying its own weight. The required fuel is uplifted from a bowser4.

Information required by the captain's computer is received via e.g. aWiFi network from a server computer in (for example) the terminal T1, asindicated by wireless signal Si from antenna 3 on the terminal which isreceived by a further antenna 3 on the aircraft. All the network signalsare preferably encrypted.

It should be noted that the DYNAMIC module as well as the other softwaremodules are preferably all run on the server computer and that thecaptain's computer acts as a thin client, providing the user interfaceand the basic network communication. Accordingly the further data aswell as the operational flight plan data can be received and processedby the server and the results transmitted (within signal S1) to thecaptain's laptop via the WiFi network. The input from the captain at theuser interface during the processing of the further data is transmittedto the server over the WiFi network. Thus the network link between theflight deck computer and the server in terminal 1 is bidirectional.

The aircraft then takes off (A′) flies (A″) to the destination and lands(A′″) at runway R2 at the destination. After taxiing to the destinationterminal T2 is completed, the captain notes the actual fuel remaining(LDG FUEL) and compares it with the predicted value (PREDICTED LDG FUEL)calculated by the DYNAMIC module. This and related data are communicatedvia antennae 3 of the WiFi network to a further computer in terminal T2,using a further software module, COMPLETE. Assuming the fuel consumptionprediction was accurate, this provides further confidence in the systemand enables the algorithms to be fine-tuned if necessary.

Further detail is given below.

Referring to FIG. 2, the relationship between the software modules M isshown. The arrows depict information flow (single direction orbidirectional) between the modules.

The modules (termed Fuel Matrix modules) are as follows:

i) Fuel Matrix DYNAMIC

This is a core application utilised by the captain of the aircraft asthe main application during pre-flight duties to assist the flight deckwith recommended fuel uplifts in line with company policies. It requiresOFP data field entries (automatic or manual) together with responses toextra fuel considerations to present recommended fuel figures. Toassist, related historical facts are provided from the HISTORICAL moduleand live data is available from the LIVE module. Typically, the timetaken by the captain for data entry is 90 seconds. The calculationmachine predominately operates within this application with inputsfrom/changes to the Fuel Matrix MANAGEMENT module tailoring thesecalculations.

ii) Fuel Matrix COMPLETE

This is a core application utilised during post-flight duties to recordactual fuel factors to enhance the Fuel Matrix LIVE and Fuel MatrixHISTORICAL modules. The average data field entry time is 45 seconds.This module is primarily for use in data collation/distribution withinthe software suite.

iii) Fuel Matrix MANAGEMENT

This is a core application utilised only by specialist airlineadministrators to define a generic or route specific benchmark and offeroptimisation and standardisation. This application inputs data forand/or modifies the algorithms utilised in the DYNAMIC module. In thismanner the DYNAMIC application can be fine tuned to influence resultsand fuel cost savings. The MANAGEMENT module also provides control forthe other modules, with the exception of the COMMUNITY module.

iv) Fuel Matrix LIVE

This is an add-on application utilised by the flight crew immediatelybefore fuelling to view user-defined live data to assist with extra fuelconsiderations. When the captain or other members of the flight crew areanswering the extra fuel consideration questions in the FUEL MATRIXdynamic application, they can check on live data i.e. most recentreports of holding at destinations, weather encountered and avoided onroutes, runways in use and other information relevant to fuelconsumption for their particular flight. This module can be customisedby different users or airlines.

v) Fuel Matrix HISTORICAL

This is an add-on application utilised by the flight crew to viewuser-defined facts derived from previous flight statistics to assistwith extra fuel considerations. When the flight crew are answering theextra fuel consideration questions in the Fuel Matrix DYNAMICapplication and reviewing recommended fuel loads, they can check onhistorical data to build confidence in the results of the fuelcalculation such as predicted arrival fuel and anticipated holding timesfor example. This module can be customised by different users orairlines.

vi) Fuel Matrix COMMUNITY

This is an add-on website chat forum application utilised bypliots/management/air traffic controllers and others to stimulate fuelcost saving and monitoring discussions (threads) with simpleuser-friendly functionality. The website can provide aviation news, fuelprices, chat forums, information on fuel related issues and the like andfeeds information to the MANAGEMENT module.

vii) ADD-ON Modules

Further modules M′ may be developed in the future and the MANAGEMENTmodule is arranged to communicate with such modules.

Referring to FIG. 3, a start-up screen on the captain's laptop is shown.He will normally log in (by clicking on button B1 with the laptop mouse)and then select the DYNAMIC module by clicking on button B5. Howeverbuttons B2 to B4 provide access to the LIVE, HISTORICAL and COMMUNITYmodules which may be accessed to provide background information forworking with the DYNAMIC module during the fuel calculation. TheCOMPLETE module is selected using button B6 after touchdown at thedestination. The MANAGEMENT module typically contains the algorithmsupon which the key calculations and reference factors rely. This ispreferably only accessible by company systems administrators authorizedto access this module and may be selected with button B7, if needed.

Referring to FIGS. 4 and 5, the MANAGEMENT module, which would normallybe operated by specialist administrators on the ground, can operateeither with generic definable parameters (FIG. 4) which are not tied toany particular route or with route-specific definable parameters (FIG.5) if these are available in running the fuel calculation algorithms.The latter provides enhanced accuracy.

Referring to FIG. 4, the MANAGEMENT module includes data entry boxes forthe aircraft type, the hourly fuel consumption of APU 1 (FIG. 1) thetime taken to start the engines 2 (in minutes) the fuel required tostart the engines, the fuel consumption per minute during taxiing andthe date of the current version of the module. These data entry boxesare shown at the head of the screen. In addition, as shown at the rightof the screen, there are data entry boxes for the CRZD factor (thepercentage that must be added to the manufacturer's nominal fuelconsumption for the aircraft type to take into account the degradationin fuel consumption of the particular aircraft being flown, due to e.g.dents in its fuselage which impair its aerodynamic performance), STATRMF (statistical remaining fuel) and STAT CONT (statistical contingencyfuel). STAT RMF and STAT CONT may be used to feed into planned landingfuel (PLF) calculations which illustrates to the flight crew the fuelthey can expect to carry on landing at the destination and can becalculated in various ways. For example, PLF can be calculated assumingall planned flight fuel is used plus an amount of the remainingcontingency fuel (CONT) multiplied by a contingency factor (cf); ormultiplying the adjusted ramp fuel value by the statistical remainingfuel value (STAT RMF); or assuming all planned flight fuel is used plusan amount of the remaining contingency fuel (CONT) multiplied by acontingency factor (cf) and multiplied by a statistical contingencyfactor (STAT CONT). Typically, all three will be calculated and thelowest will be displayed as PLF value to the flight crew. As more databecomes available, the statistical factors become more reliable and thePLF will be more accurate.

The MANAGEMENT module also utilizes, for example, six independentparameters GP1 to GP6 which are associated with respective fuelquantities which collectively make up the total fuel requirement fromrunning the APU 1, starting the engines 2, taxiing from terminal T1,take-off from runway R1, the flight to the destination, holding abovethe destination, landing on runway R2 and taxiing to terminal T2.

Each of the above parameters GP1 to GP6 is associated with a contingencyvalue CONT GP1 to CONT GP6 respectively (certain values of which arelisted in column C1 in FIG. 4) and these represent additional weights offuel which must be carried in order to satisfy contingencies such as theneed to avoid bad weather and the like. Collectively, CONT GP1 to CONTGP6 represent the total additional fuel required to satisfy allrecognised contingencies.

Importantly, GP1 to GP6 are modified in dependence upon answers tocertain questions Q1 to Q6 (described below in relation to FIG. 6)presented by the DYNAMIC module to the captain on his laptop screen (hisuser interface). The effect is shown in columns C2, C3 and C4. Theparameter number is shown in column C2, the yes/no answer (Y/N) is shownin column C3 and the effect in terms of extra fuel is shown in columnC4. For example, referring to the first row (question Q1) in C2, C3 andC4, if the answer to question Q1 is “No” then GP2 is raised by 1000 kg.No values are given for the final row (Q6) because this is unused in thepresently described embodiment—extra fuel considerations may be furtherdefined and a relevant question or questions inserted here.

Thus contingency fuel is analysed by contingency and adjusted inresponse to answers to simple questions given by the captain immediatelybefore fuelling.

Column C5 and column C6 show certain relationships between contingencyfuel values (“CONT LIMIT”) and a contingency factor (“CONT FACT”). Forexample if the contingency fuel is greater than 2000 kg, then thecontingency factor is 0.5. If the contingency fuel is only 600 kg, thenthe contingency factor is unity. The contingency factor is a probabilityfactor utilised in an algorithm for calculating the probable weight offuel remaining on landing at the destination.

The text entry boxes in columns C1 to C4 can be filled in by theadministrator. Selection buttons B at the foot of the screen allow theadministrator to perform the operations indicated on those buttons.

Referring now to FIG. 5, if route-specific parameters are available thenthey are used. For example if a route involves flying over water,slightly different fuel consumption may result. This can be taken intoaccount using route-specific parameters.

It will be noted that the screenshot of FIG. 5 shows the aircraftregistration code (in this case G-ABCD), the flight number (“FLT NBR”)and the destination (“DEST”) code (in this case EGKK) which are notincluded in the generic screenshot of FIG. 4. Otherwise the screenshotsare similar, and in particular, columns c1 to c4 relate to the answersto questions Q1 to Q6 in the same manner as columns C1 to C4 relate tothe answers to these questions, although the values entered by theadministrator in the text entry boxes of c4 differ from thecorresponding values in C4.

The constraints represented in columns c5 and c6 are comparable to thoseof columns C5 and C6 (FIG. 4) respectively.

FIG. 6 shows the information presented interactively to the captain bythe DYNAMIC module as he determines the quantity of fuel to uplift (loadonto) the aircraft, this quantity being known as the “adjusted rampfuel” and indicated as “ADJ RAMP FUEL” namely 53.5 metric tonnes in thisexample.

The top left-hand region of the screen shows “OFP DATA,” namely theflight number (“FLT NBR”) and aircraft registration code (“AC/REG”), thedestination (“DEST”), the expected fuel consumption (“TRIP”) for theflight itself (i.e. take-off to landing but excluding taxiing, excludingstarting up the engines 2 and excluding 30 minutes running the APU 1)the fuel required (“T/O FUEL”) for the flight itself at take-off (i.e.fuel required minus TAXI fuel requirement), the degradation in fuelconsumption performance during flight, expressed as a percentage of thenominal fuel consumption of that aircraft type, for the particularaircraft (“CRZ DEG”) and the estimated zero fuel weight (“EZFW”) andestimated take-off weight (“ETOW”) which is equal to EZFW+T/O FUEL. Theactual zero fuel weight on take-off (“AZFW”) is not known at the time ofpreparation of the OFP, is not included in the OFP, and therefore is notOFP data. However, once this parameter is known, it is entered by thecaptain in the AZFW box.

Finally, the OFP section includes boxes MS and PS for the deletions andadditions of fuel respectively per 1000 kg of fuel subtracted from oradded to the T/O FUEL value. For example if the AZFW were 3,000kilograms less than the EZFW, and this resulted in a reduction in thecalculated fuel requirement of 1,000 kilograms, a further reduction 173kilograms could be made to take into account the saving in fuelotherwise required to carry the 1000 kg of fuel to the destination.

The EXTRA FUEL CONSIDERATIONS section of the screenshot shows an exampleof six questions Q1 to Q6 with (in the case of Q1) an associated textentry box and in case of Q2 to Q5 YES/NO buttons. These questions are asfollows:

PARKING TO ACTIVE RWAY: The expected taxiing time (in minutes) to theactive runway R1 (FIG. 1) which may differ from the taxiing time to therunway assumed in the operational flight plan (OFP) as a result of alast-minute change to the runway selected, e.g. as a result of a changein wind or as a result of noise abatement procedures;

ATTAIN YOUR PLANNED FLS? Are the flight levels (defining altitudes ofdifferent sections of the flight) specified in the OFP going to beattained?—they may not be as a result of Air Traffic Controlrestrictions, other aircraft already occupying the requested flightlevels, etc, after generation of the OFP. A change in flight level canchange the calculations for fuel consumption requirements for theflight.

ANTICIPATE DEST HOLDING? Is holding anticipated at the destination (e.g.as a result of air traffic congestion, bad weather, earlier delays,etc)?

-   HOLDING FOR +10 MINS: Assuming an affirmative answer to the previous    question, is the holding period expected to be greater than 10    minutes?

DEST WX NEAR MINMAS? Is bad weather (possibly necessitating a landing atan alternate airport) expected at the destination?

LVP IN FORCE? Are low visibility procedures in force?

In this example, Q6 and its associated answer button are greyed outbecause it is known that such procedures are not in force—so thequestion is assumed answered in the negative.

The captain can access real time live data via has laptop (e.g. weatherconditions en route, waiting times at destination airport, etc), usingthe LIVE module (which, in common with the other software modules, ispreferably run on the remote server). Additionally he is made aware ofhistorical statistical data (e.g. typical holding times) relevant to thesector by the HISTORICAL module. These sources of information inform hisanswers to the above questions.

In response to the captain's answers to questions Q1 to Q6 betweenboarding the aircraft and fuelling, and in response to the captainselecting the CALC button B to confirm these answers, the DYNAMIC moduleruns a set of algorithms to calculate the following (as an example) inthe CALCULATED FINAL FIGURES box:

ADJ RAMP FUEL: the adjusted ramp fuel value, i.e. the weight of fuel intonnes required to be uplifted to the aircraft A from the bowser 4 atthe ramp position;

TRIP: the amount of fuel in tonnes required for the flight, i.e. whilethe aircraft is airborne, and

TAXI: the amount of fuel in kilograms required for taxiing to the runwayR1.

The pilot can accept the resulting figures (by selecting the ACCPTbutton B) and upload the fuel, or can reject the resulting figures (byselecting the REJCT button B). The latter choice brings up a furtherscreen (not shown) giving the opportunity to override the calculatedvalues, but if the manually selected values are outside safe limits, theDYNAMIC module displays an appropriate warning message.

All of the captain's decisions regarding fuel uplift are recordedelectronically on the OFP which is retained after the flight to meetlegal requirements. Optionally, this data may also be retrieved by theairline management for monitoring of flying efficiency and the effect ofthe decisions of the Captain may be reviewed to identify flaweddecisions, requirement for training etc, as a management tool.

The screenshot of FIG. 6 also includes a HISTORICAL FACTS section whichdisplays the EXPECTED HOLDING (time)—in this case 8 minutes and thePREDICTED LDG (landing) FUEL (in tonnes). The former figure is generatedby the HISTORICAL MODULE and the latter is generated by the DYNAMICMODULE.

Examples of the algorithms run by the various modules will now bedescribed in general terms, before describing the screenshot of FIG. 7which is generated by the COMPLETE application after landing at thedestination.

The algorithms are typically run in three stages as follows:

-   i) In a preliminary step the route is checked to see whether    route-specific definable parameters are available—if not then    generic definable parameters are used (see the screenshots of FIGS.    4 and 5). Units are converted to metric if necessary.-   ii) The following main algorithms are run:-   ctaxi (to calculate the fuel required for taxiing)-   arf (to calculate the adjusted ramp fuel)-   ctf (to calculate the trip fuel i.e. fuel consumption during the    flight including take-off and landing)-   plf (to calculate the planned landing fuel i.e. the fuel remaining    on landing)-   iii) To complete the process, a fuel saving value and/or a carbon    dioxide reduction value are calculated and a safety check is run to    ensure that the fuel carried and take-off and landing weights are    within safe limits.

Optionally, a further step iv) may be incorporated, either byincorporation in the process above or by using a separate module, inwhich various calculations that are currently carried out, e.g. inrespect of Tankering, Cost Index, Re-Clearance and Alternate AirportSelection and/or Optimum Route Selection, using only Fuel Cost and Timeparameters may be advantageously refined, for example by using, inaddition, carbon trading or emissions-trading information. Suchcalculations may form an independent module or be incorporated into theplf algorithm. This optional step is set out in more detail below usingTankering as an example to demonstrate the application. Accordingly, inan example of a further step, Tankering Fuel calculations may be carriedout (this may be included in the plf algorithm). Some airlines includein fuelling calculations implications of the varying fuel costs atdifferent locations, because the planned flight comprises more than oneleg, e.g. from A landing at B and flying on to land at C. For example,where the fuel cost at a destination airport (B) is significantly higherthan the starting airport (A), the OFP may direct additional fueling tosave costs, even allowing for the fuel burn required to carry the extrafuel to the destination (B) to enable onward flight to destination (C)without purchasing more fuel. This is a procedure known as Tankering.The method and apparatus of the present invention may also allow for aTankering procedure to be implemented in the most efficient manner sothat any Extra Fuel may be uploaded allowing for calculated requirementsfor Tankering Fuel. By using, for example, the LIVE module, up-to-daterelative fuel cost data may be provided, and the cost efficiency of theTankering procedure maximized to that particular flight using a furtheralgorithm provided, for example, by the DYNAMIC module (or a separateTANKERING module). Furthermore, the LIVE module may provide access toup-to-date carbon trading or emissions-trading information, and suchdata included in the Tankering Fuel calculation, in particular in thefuel burn associated with Tankering, the cost not only of the purchaseof the fuel but also the carbon trading cost of Tankering fuel-burn. ATankering calculation can be provided as part of the method and systemof the invention described hereinbefore or as a separate module.

Additionally, there is provided in a further aspect of the invention asystem for the calculation of the optimum cost-efficient amount ofTankering fuel for an aircraft flight from a pre-determined departurepoint to a pre-determined destination point, the system comprising aprogrammed computer arranged to determine a Tankering fuel-burn rate forsaid flight on the basis of operational flight plan data and furtherdata relevant to fuel consumption for that instance of the flight, saidcomputer configured to receive input data on cost of fuel at departureand destination and carbon trading costs associated with the flight andconfigured to calculate from said Tankering fuel burn rate and saidinput data an optimum Tankering fuel load for the flight.

In a still further aspect, there is provided a method for the fuellingof an aircraft with Tankering fuel for a flight from a pre-determineddeparture point to a pre-determined destination point, wherein the fuelrequirement for the flight is determined, an optimum Tankering fuel loadis determined by Tankering fuel calculation software from a calculatedTankering fuel-burn rate, the differential cost of fuel at thedestination point and the departure point and the carbon trading cost ofTankering fuel-burn for the flight, said Tankering fuel-burn rate beingdetermined on the basis of operational flight plan data and further datarelevant to fuel consumption for that instance of the flight, andsubsequently fuel to meet said fuel requirement and a determined optimumamount of Tankering fuel is uplifted to the aircraft under the controlof the user.

Tankering fuel is defined here as the amount of extra fuel required atdeparture point to achieve a certain amount of extra fuel remaining atthe destination (destination-Tankered fuel). That is, the Tankering fuelis equal to the destination-Tankered fuel plus the Tankering fuel-burn(that is, the fuel burn associated only with carrying extra Tankeringfuel).

Preferably, the same data sources and calculations used to determine afuel requirement for a flight is adapted and used to determine theTankering fuel-burn.

With reference to the algorithms referred to above for the purpose ofputting the invention into effect according to one embodiment involvingdefined steps i), ii) and iii), steps i) and iii) do not require furtherexplanation. The algorithms of step ii) are given by way of Examplebelow. Generic or route-specific parameters available to the algorithmsare shown in italics and variables entered on screen (see the abovediscussion of the screenshots) by the captain or flight crew orcalculated by a preceding algorithm from such entered variables areshown in bold.

EXAMPLE

ctaxi Algorithmctaxi=(apuf×0.5)+esf+((tt−est)×tf)

-   ctaxi is the total fuel consumption involved in taxiing.-   apuf is the hourly fuel consumption of the APU 1. The 0.5 figure    represents the assumed half-hour run time of the APU.-   esf is the fuel required to start the engines 2.-   tt is the taxiing time and is entered by the captain/flight crew    (see question Q1 in FIG. 6). The HISTORICAL algorithm of FIG. 6    provides historical data, adjusted for seasonal changes, for this    parameter which can be used to guide the answer to question Q1.-   est is the time taken for the engines to start, normally 1 to 2    minutes.-   tf is the rate of fuel consumption during taxiing.

arf Algorithms 1) and 2)

-   1) Required code: zfwdiff (zero fuel weight    difference)=(AZFW−EZFW)/1000-   (The divisor of 1000 converts from kilograms to tonnes)

If zfwdiff positive then×zfwdiff by PS=PSzfw

If zfwdiff negative then×zfwdiff by MS=MSzfw

(MS and PS are shown in the OFP DATA section of FIG. 6).

-   (cg1 and cg2 etc are contingency groups, which control fuel additive    questions—if there is a high CONT, there will be answers that do not    require an additive question)-   If CONT≦cg1 then

if Q5=Yes then tof5=p5

(see question Q5 and CONT in FIG. 6)

-   -   If CONT≦cg2 then

if Q1=No then tof1=p1

if Q2=Yes then tof2=p2

if Q3=Yes then tof3=p3

-   -   (see questions Q1 to Q3 in FIG. 6)

If CONT≦cg3

-   -   Q4=Yes then tof4=p4    -   if CRZ DEG=P then tofcrzd=crzd×crzdf×CONT

(CRZ DEG is cruise degradation—a cruise degradation figure is applied toan aircraft to account for the variation in fuel burn as a result of ageand imperfections. The higher the value attributed to CRZ DEG, the morelikely it is to have a small fuel additive to account for it).

-   2) Required code: newtof (new take-off fuel)=tof ((+PSzfw) or    (−MSzfw))+tof1+tof2+tof3+tof4+tof5+tof6+tofcrzd-   (thus newtof is the New Take-Off Fuel weight i.e. the actual weight    of fuel at take-off) arf=newtof+ctaxi

ctf Algorithms

-   Required code: atow (actual take-off weight)=AZFW+newtof-   Required code: towdiff (take-off weight difference)=(ATOW—ETOW)/1000

If towdiff positive then×towdiff by PS=PStow

If towdiff negative then×towdiff by MS=MStow

-   ctf=TRIP ((+pbtow) or (−mbtow))

(AZFW, ETOW and TRIP are given in the OFP data section of FIG. 6).

plf Algorithms

Required code: cf (contingency factor) (this defines the contingencyfactor: it is assumed that a small amount of CONT (contingency fuel) maybe used up on a flight and a large portion should be expected,typically, to remain unused; i.e. if the CONT fuel is expected to beless than or equal to a defined contingency limit (e.g. c11) then afirst contingency factor applies to cf-relevant calculation, if not thenthe same test is carried out relevant a further contingency limitassociated with a further contingency factor, until the appropriatecontingency factor is determined).

If CONT≦c11 then cf=cf1 or

If CONT≦c12 then cf=cf2 or

-   -   If CONT≦c13 then cf=cf3 or    -   If CONT≦c14 then cf=cf4 or    -   If CONT≦c15 then cf=cf5

-   plf=arf−ctf−ctaxi−tof1−tof2−tof3−tof4−tof5−tof6−((CONT−tofcrzd)×cf)    (this defines predicted landing fuel=adjusted ramp fuel—calculated    trip fuel—calculated taxi fuel—[fuel additives]—expected used part    of contingency fuel)

-   or

-   *plf=arf×srmf

-   or

-   *plf=arf−ctf−ctaxi−tof1−tof2−tof3−tof4−tof5−tof6−((CONT−tofcrzd)×scont)

*These possibilities involving statistically derived parameters srmf andscont can be used when sufficient data has been collated by the COMPLETEMODULE.

Referring now to FIG. 7, when the aircraft has landed at itsdestination, the COMPLETE module is run to acquire, either manually fromthe flight crew or automatically from aircraft instruments, the FLIGHTDATA and ACTUAL FUEL FACTORS shown. The latter correspond to the (withhindsight) correct answers to questions Q1 to Q6 of FIG. 6. Thisinformation is saved (by selecting a button B) and fed to theHISTORICAL, MANAGEMENT and LIVE modules (FIG. 2) for current and futurereference.

1. A method of fuelling an aircraft for a flight to a predetermineddestination wherein the aircraft is loaded, the actual zero fuel weightof the loaded aircraft is determined, the fuel requirement of the loadedaircraft for that destination is calculated by fuel calculation softwareon the basis of operational flight plan data, said actual zero fuelweight, and further data relevant to fuel consumption for that instanceof the flight to the predetermined destination, said further data beingprocessed interactively by the user by means of a user interface to saidfuel calculation software, and subsequently fuel to meet said fuelrequirement is uplifted to the aircraft under the control of said user.2. A method according to claim 1 wherein the user interface is on theaircraft.
 3. A method according to claim 1 wherein said further data isentered at said user interface by the user.
 4. A method according toclaim 1 wherein the operational flight plan data includes statisticaldata based on previous instances of flights to said destination and themethod includes means for reporting actual fuel consumption data aftersaid flight.
 5. A method according to claim 4 wherein actual fuelconsumption data is processed by a user during said reporting.
 6. Amethod according to claim 1 wherein said further data takes into accountone or more of the following: i) taxiing to a runway different from thatin the operational flight plan; ii) operating at a flight leveldifferent from that in the operational flight plan iii) holding at thedestination; iv) weather avoidance, and v) low visibility procedures. 7.A method according to claim 1 wherein the quantity of fuel remaining onarrival at the destination is calculated in dependence upon said furtherdata.
 8. A method according to claim 1 wherein contingency fuelcalculated in accordance with the operational flight plan isre-calculated in dependence upon said further data.
 9. A computerprogram product comprising a computer-readable medium incorporatingprogram code executable by a processor to implement a method as claimedin claim
 1. 10. An arrangement for calculating the fuel requirement ofan aircraft flight to a predetermined destination, the arrangementcomprising means for determining the actual zero fuel weight of theaircraft after it has been loaded, a programmed computer arranged todetermine a fuel requirement for said flight on the basis of operationalflight plan data, said actual zero fuel weight, and further datarelevant to fuel consumption for that instance of the flight to thepredetermined destination, said computer being programmed to processsaid further data interactively with a user at a user interface thereof.11. An arrangement according to claim 10 wherein said computer isarranged to receive said further data as an input at said user interfacefrom the user.
 12. An arrangement according to claim 10 wherein the userinterface is on the aircraft.
 13. An arrangement according to claim 10which comprises a computer network including a first terminal which inuse prompts the user to enter said information, said terminal beinglocated on the aircraft, and a second terminal which in use transmitssaid operational flight plan data to said first terminal over saidnetwork.
 14. An arrangement according to claim 13 wherein said firstterminal is arranged to transmit actual fuel consumption data for thecompleted aircraft flight to the network.
 15. An arrangement accordingto claim 13 wherein the network is arranged to run a plurality ofsoftware modules which exchange information, the modules including aninteractive fuel calculation module which calculates said fuelrequirement and at least an operational flight plan module whichgenerates said operational flight plan data.
 16. An arrangementaccording to claim 10 which in use acquires actual fuel consumption dataat the end of the flight and stores the actual fuel consumption data foruse in a future operational flight plan.
 17. An arrangement according toclaim 10 wherein said further data takes into account one or more of thefollowing: i) taxiing to a runway different from that in the operationalflight plan; ii) operating at a flight level different from that in theoperational flight plan iii) holding at the destination; iv) weatheravoidance, and v) low visibility procedures.
 18. (canceled) 19.(canceled)
 20. (canceled)